Existing process control systems evolved out of the pneumatic and electronic analog control systems that preceded them. These early control systems were designed to provide process control functions for a control loop or a number of related control loops of a production process in an autonomous or semi-autonomous, but coordinated manner, with the coordination often being achieved through the appropriate settings of set points across the multiple controllers. As such the architecture of early control systems was aligned to the process flow of the production process with each control typically limited to the control of a very small component of the overall production flow of the operation. As a result, each controller could be reasonably applied to the component of the operation it was responsible to control.
With the introduction of digital computer technology as the delivery vehicle for process control, the potential scope of automatic coordinated control increased dramatically. But in order to make these emerging digital control systems market acceptable they were programmed to directly replicate the functionality and architecture of the analog systems that preceded them. To accomplish this, one solution provided a software configuration environment for process control based on “software blocks” to perform the exact functions of the analog control system components. As such, the control system architectures that evolved after the initial introduction of digital technologies were aligned to the process flows of the production operation and therefore were designed to be configured to control from a process-centric perspective. This alignment and architecture worked quite well for the last 60 years and has been the basis of process control system software design ever since.
Initially, the job of configuring the process control functions in these process-centric automation systems was effectively accomplished by the engineers in industrial plants who had configured the traditional analog control systems. This was because the control software was designed to replicate the functionality and components of analog control systems. The transfer of knowledge from analog to digital control was very effective.
The scope of control of many of the early digital control systems was typically about the same scope that had been implemented in analog systems. Perhaps, this was due to the fact that the specifications of control systems had been done with the thought being that an analog control system would be utilized or perhaps it was due to the comfort level of the engineers experienced using analog systems. In any case, as digital systems were introduced, the scope of control did not tend to expand to the potential offered by digital control systems. During this phase the limitations of process-centric designs did not become obvious.
Over time, as process control engineers became more proficient and comfortable using digital process control systems, a natural tendency arose to want to integrally control larger and larger operational domains with a single automation system. During the 1980s there was a push to control entire process units in a coordinated manner. Over time, a desire emerged to control entire plant areas, trains, and even entire plants utilizing a single coordinated control strategy. The belief was that the more unified and coordinated the control strategy could be across larger operational domains, the more efficient the operation would be. However, a significant limitation to the process-centric design of the automation systems surfaced that made implementation of such a strategy not feasible. A process-centric perspective of a few control loops or, perhaps even an entire process unit seemed manageable, but as the scope increased the complexity increased exponentially. A process-centric view over large operational domains presents complex and challenging coordinated control challenges as illustrated by the example piping and instrument diagram 100 of a partial operation depicted in FIG. 1. In fact, the complexity of the process-centric perspective was so extreme that only the industrial operations with huge central engineering functions continued to move toward large domain coordinated control. Most industrial operations continued to control their plants much in the same manner as they had during the analog control system period. As a result, much of the potential benefit of moving from analog to digital control was not realized.
A new class of control system known as Enterprise Control System (ECS) was designed in an effort to enable large domain coordinated control by combining the traditional digital control system technology with open industrial software. Although the combined architecture was a step forward, the process-centric approach to control strategy design still limited the effective scope of coordinated control strategies.
The process-centric design of traditional control software remained as a preferred way of developing control strategies by industrial and industrial automation suppliers. When batch control strategies became available, it helped simplify some of the complexities of the process centric automation and control systems. Batch control strategies require a low layer of process and logic control for the basic equipment and loops in a plant. But over this basic control is a higher level of batch control in which the control is oriented to the process units, trains, areas and the products being produced in them. Although the batch control strategies were much simpler than if they had been attempted through the strict process centric perspective, the complexity level associated with engineering, operating and maintaining the automation and control system remained relatively high. Moreover, the batch control strategies also did not address various challenges related to reliability and integrity of the system, for example, in the event of failure.